[miniflare] Add backend resources for email capture and storage - #15064

🟡 Emails sent just before the dev session shuts down are never written to disk or logged

The on-disk copy of a sent email and its log line are queued to run in the background (this.ctx.waitUntil(...) at packages/miniflare/src/workers/email/send_email.worker.ts:370 and :451) instead of being finished before the send call returns, so a script that sends an email and then immediately shuts the local dev session down loses the saved message entirely.

Impact: Short-lived usages (for example sending through getPlatformProxy() and then disposing) no longer reliably produce the .eml/text/HTML/attachment files or the "send_email binding called..." log they used to.

Was this helpful? React with 👍 or 👎 to provide feedback.

so because these have different semantics to the actual endpoints, we need to stick these in the local namespace. otherwise it will cause confusion between the 'real' api and this one

(https://developers.cloudflare.com/api/resources/email_routing/methods/get)

what do you mean by address-based routing? the port? that won't hold because there can be multiple workers per port. you could either use the worker name as part of the path or make this required

hmmm. as in you would want a 200 exception if the handler intentionally threw?

task failed successfully i guess 😅

Yeah this is a weird situation because the message was sent successfully, just the worker itself didn't like it. This is a confusing way to express it but I felt using a non 200 status would make it seem like the send itself failed. I'll make it clearer in the docs whats actually happening, unless youd have a different preference to how its handled?

could this be a query param on GET /email/routing above

The list and detail items have a different shape so i thought it would be appropriate to keep separate, if not I can make this change?

similarly to above, query param on the main list endpoint?

this could be a discriminated union to show that messageId is only available when the type is forward or reply

why not an array of objects?

there's quite a lot of repetition in these objects with from/to/subject/messageId etc.

could you define an object like 'base_email' and extend that?

🟡 Fallback worker name setting is registered twice on the dev server, creating a conflicting duplicate

The entry worker's fallback-worker-name value is added a second time (serviceEntryBindings.push with json: JSON.stringify(fallbackWorkerPublicName ?? "") at packages/miniflare/src/plugins/core/index.ts:799-802) even though the same setting is already provided later in the same list, so the dev server ends up with two conflicting entries for one name.
Impact: The local dev server may refuse to start or silently pick the wrong value for which worker handles unrouted requests and received emails.

In getGlobalServices (packages/miniflare/src/plugins/core/index.ts), the binding CoreBindings.TEXT_FALLBACK_WORKER_NAME is now pushed twice into serviceEntryBindings: once as a json binding near line 799-802 (value fallbackWorkerPublicName) and once as a text binding near line 928-931 (value workerNames[0]). This creates a duplicate binding name on the SERVICE_ENTRY worker. Consolidate these into a single binding definition (they carry the same first-worker name), and remove the now-redundant duplicate type entry in packages/miniflare/src/workers/core/entry.worker.ts (TEXT_FALLBACK_WORKER_NAME is declared twice in the Env type). Ensure the retained binding provides the value the entry worker expects for routeTarget/Access-blob lookup and the email workerName.

Was this helpful? React with 👍 or 👎 to provide feedback.